Google Summer of Code finished recently. This is the first year that I have participated as a mentor for the
Debian Project. Its a big responsibility to be part of the Debian team and to be one of the Debian team members
representing Debian at the GSoC Mentor Summit.
Birthdays all round
This has been a particularly important year for the Debian Project, as the project celebrated our
20th birthday recently, on 16 August 2013, one of the final days of
DebConf13 in Switzerland. GSoC celebrates its 10th year in 2014, with a generous 10% boost in the student stipend to mark the occasion.
Google: don't be evil
Google's "Don't be evil" approach to business has always been an interesting point for discussion. In my view, there are few cases of absolute good or absolute evil that we can universally classify and agree on.
At a more pragmatic level, various people have commented that GSoC is a recruiting program for Google: some have even cited this as a reason not to participate. This is a more interesting point for discussion. The results of the program are not exclusive to the headhunters at Google. Anybody can browse through the
Debian GSoC weekly student reports from each student to find out exactly what the students were up to and try to recruit them. Mentors and the projects they belong to have not been forced to sign any wide-ranging non-disclosure agreements or non-compete agreements with Google. In one recent example, the
xWiki open source project even went as far as
setting up a new office in Romania and employing some former GSoC students on a permanent basis.
Assorted images from Iasi, Romania, where xWiki set up an office employing former GSoC students
How does Google benefit then? Well, there appear to be several possibilities:
- Generating a huge amount of goodwill and recognition for the value that they place on the development of the next generation of software engineers
- Stimulating the expansion of high quality free software projects, many of which they use directly or indirectly for their internal projects
- Access to private evaluations prepared by the mentors. These evaluations don't take more than an hour for the mentors to complete but they do serve to give Google's headhunters a slight headstart over anybody else who is scouring the web for the names of graduates who completed GSoC
Overall, it appears to fit the definition of a "win-win" scenario: yes, Google gets stuff out of it, but the benefit is not exclusive to Google and projects like Debian are winners too.
My initial approach
I started by reviewing some of these materials:
One particular concept that I took note of was the need to give students some opportunity to be innovative and original in their
project proposals. In other words, it has been suggested that students should not be given a precise specification: rather, they should be given some very general concepts or goals and asked to suggest some funky, innovative new idea.
The wisdom of this approach varies. If your free software project has some very specific gap that you need to fill, you may only be interested in taking a student who can fill that gap and you may not want to waste the time of other applicants. On the other hand, if you do precisely document this gap you want filled, you may get a bunch of very similar proposals from students and it may be more difficult to distinguish which of them is the most desirable candidate. Furthermore, if your expectations are too rigid, you may not benefit from a top-gun coming in and contributing some really exciting piece of work that you hadn't even thought of.
In the end, I opted for providing more generic project briefs and looking at how students responded. The briefs that I published are
available here.
Coding tasks during the selection process
There is no doubt about it, coding tasks are an important part of ensuring students are capable of development work before they are selected.
They are also very important for us as mentors. It is not uncommon for some of us to be completely out of touch with the capabilities of other developers. The coding tasks completed by the students during the selection phase allow us to get a feel for their capabilities and set reasonable expectations for how much they can achieve during the course of the project.
To simplify the management of coding tasks and engage the students in the Debian community at large, I decided to create tasks as wishlist items in the Debian bug tracking system,
such as this dynalogin bug report. The prospective GSoC students were asked to put their name in the bug tracker to take ownership of the task they would complete.
Student project proposals
For the real-time communications project, I felt all the students slightly underestimated the complexity of this field and would have to be extremely lucky to complete everything they hoped to. After all, this is a field that the free software movement has been wrestling with for years without gaining the upper hand. For somebody with good knowledge of the projects in this space, it is possible to guide the students towards meaningful and achievable subprojects.
Nonetheless, the proposals were useful for me in understanding which part of the topics were most attractive to the students.
For the other project areas, the student proposals were slightly more specific. Fabian's appeared to be the most specific and well considered proposal for the one-time-password project, in fact, it appeared very much like a project that he could work through from start to finish.
Debian teamwork
Anybody looking at the GSoC web site will notice that there is a certain amount of overhead in joining the program, promotion, payment administration and optional participation in the GSoC Mentor Summit.
As a large organisation, Debian established a dedicated
SoC administration team who looked after the GSoC and
Outreach Program for Women administrivia.
As a developer and mentor, I found this arrangement was highly effective and allowed me to focus over 99% of my efforts on the front-line work, selecting students and supporting them through their projects.
Project results
One of the more controversial issues during the Debian 7 (wheezy) release cycle was the inclusion of the
Mumble voice conferencing software. Although the software has some serious issues, it was eventually escalated to the technical committee
and allowed to remain in Debian, partly due to lack of any alternative.
One of the first results from Catalin's project was the creation of an alternative, the new
reConServer project, based on the
librecon conversation manager API from the
reSIProcate SIP stack. reConServer is a significantly more generic solution than Mumble, as it allows any SIP peer to participate in an audio conference. It supports
TURN for NAT traversal too. Catalin then went on to make the first working implementation of a scheme for
passing context information from a web site to SIP WebRTC call as described in the IETF draft. All work has been integrated into release tarballs and packaging.
Fabian worked through the latest standards for one-time passwords, extending the
oath-toolkit and
dynalogin projects to implement mutual two-factor authentication with just about any arbitrary crypto suite using one-time passwords. This work is yet to be merged into an official release of dynalogin as it requires co-ordination with the
oath-toolkit release and package updates. However, there is a compelling demonstration in his
video from DebConf13 and the
source is available under Fabian's github account.
In the post-Snowden world, the work from both of these student projects will be hugely valuable to people wanting to tighten up their computer security and communication security practices.
The development process
Deciding to mentor more than one project turned out to be a worthwhile decision. At first, this might seem like a big risk but it is manageable with support from co-mentors. The upside is that different students work at different speeds, they have different code styles, they even work at different times of the day or week and mentoring more than one student/project allows the mentor to gain a better appreciation of how the students differ than if mentoring only a single project.
For Catalin's project, it became obvious at an early stage that he would benefit from having a dedicated server to run the VoIP applications on public IP addresses and low-latency networks while testing them. I spun up a virtual machine with IPv4 and IPv6 in my
Xen Cloud Platform and this was extremely helpful for both of us.
Throughout the project, I took a hands-off approach and often left the students to their own devices. I gave some suggestions to Catalin about the object-oriented design and this was enough for him to fill in the gaps and write all the code by himself. Fabian's project had fewer ambiguities and he was able to use existing code as a model more frequently than Catalin. It is possible that the students may have produced more code if I had thought through the designs myself and given them definite blue-prints. However, I feel that this would have made it harder for me to appreciate their own abilities and test the limits of their design skills.
DebConf13 participation
One of the highlights for the students was
their participation in DebConf13. Both students presented a session at the conference showcasing some of their work.
The
DebConf video team produces high quality videos of all sessions at the conference and this in turn provides some great evidence of the students' capabilities and what GSoC adds to Debian and the wider free software universe.
I would encourage other mentors to actively contemplate ways to involve their students in conferences during or shortly after the completion of their project work.
Looking ahead
Google has recently confirmed that
Google Summer of Code will be repeated in 2014. It is the 10th anniversary of the program and to celebrate, students will get 10% extra pay.
Thank you
There are many people to thank for the success of these projects and the wider success of the Debian GSoC team:
- The Debian GSoC and OPW organisation admin team
- Google and the Google Open Source Programs Office
- All the co-mentors who assisted on these projects with me: Simon Josefsson, Luke Faraone, Sylvain Berfini, Eloy Coto and Jes s P rez Rubio
- The students themselves, C t lin Constantin U urelu and Fabian Gr nbichler
- All the other very capable and motivated students who applied, submitted code samples but were not selected to participate: many of these students could have also completed a successful project and turning them away is one of the most difficult tasks for mentors in a volunteer organisation like Debian
Reproducible builds ecosystem at FOSDEM
Last years FOSDEM featured one talk about Reproducible Builds, while this year there will be four at least:
On Saturday, there will Reproducible and Customizable Deployments with GNU Guix by Ludovic Court s which which I definitly will be attending!
And on Sunday there will three talks and I plan to attend them all: a rather general one about the Reproducible ecosystem by myself, followed by ElectroBSD - Getting a reproducible BSD out of the door by Fabian Keil and finally Reproducible builds in FreeBSD packages by Baptiste Daroussin.
The FOSDEM organizers also reached out to me for an interview with me about all this reproducible stuff. I hope you'll like my answers as I enjoyed the questions 
But there are many more interesting talks (hundreds they say) and so I'd appreciate if you could share your pointers and explainations, whether here on planet, or on IRC or IRL!
What happened in the 
Nearly 40 participants from 14 different free software project had very busy
days sharing knowledge, building understanding, and producing actual patches.
Anyone interested in cross project discussions should join the 
Infrastructure
Several discussions at the meeting helped refine a shared understanding of what
kind of information should be recorded on a build, and how they could be used.
Daniel Kahn Gillmor sent a 
My previous blog posts about 
WebRTC: premium voice/video chat in modern browsers, no plugin required
Another member of Debian's GSoC program, 
As the grand finale, we took 
The grand-finale of the 
The last week was quite productive as I was on vacation and at home town but sadly I
couldn't complete this post so again merging the work with this week but this week ain't
much productive as I was tired from journey back and didn't get enough time to recover.
So here it goes.
Debian Related
Wonderful jazz concert at 
The Debian Python Modules Team is 
And while I was on it, I thought I could do the same for the GNOME and GStreamer teams:
(hint: pox-guest and piotr in python-modules are the same person)
This is the highest bug number as of now.
Will we turn bug #500000 this week-end? This is fairly unlikely. So, the best chances to win the